ΓÇó Corrupted files will produce unexpected results. This includes generation of huge output files, garbled files, and sometimes the machine will crash or hang. If this behavior occurs, the file has been corrupted. You may not have transmitted the file in binary mode, or the file may have been transmitted with errors.
ΓÇó If the resource fork of a file is corrupted, then when MacCompress adds the 'ZIVH' resource during compression of Unix format files, strange behavior may occur. I had this happen with a MacWrite file; MacWrite exhibited the same behavior when I tried to save the document (both programs filled up the disk).
ΓÇó If you are a particularly inquisitive individual, you will notice that compression of some files with resource forks, followed by decompression followed by recompression will produce slightly different numbers for the compression "bytes out". Do not be alarmed; this is apparently due to the workings of the file system doing something in the resource fork; the files actually are slightly different, so this kind of operation will necessarily produce slightly different compressed files.
If you still don't believe me, you can verify this same behavior with Stuffit; archiving followed by unarchiving followed by archiving will produce slightly different compression figures. In all cases, of course, the size of the decompressed file will be exactly the same as the original, regardless of how it was compressed.
ΓÇó some files, such as LightspeedC projects, can be compacted upon decompression (this is done by the resource manager), resulting in a smaller size than the original. Therefore, output sizes may not match input sizes (this should occur only when using Unix format).
